In Third Generation Partnership Project (3GPP) Long Term Evolution (LTE), including LTE-Advanced, Physical Downlink Control Channels (PDCCHs) are used to transmit various types of information from the network (i.e., from the enhanced or evolved Node B (eNB)) to mobile terminals (i.e., User Equipment devices (UEs)). In particular, PDCCHs are used to transmit the following messages:                Downlink scheduling assignments, including Physical Downlink Shared Channel (PDSCH) resource indication, transport format, Hybrid Automatic Repeat Request (HARQ) information, transport block size, Multiple Input Multiple Output (MIMO) related control information (if applicable), and Physical Uplink Control Channel (PUCCH) power control commands,        Uplink scheduling grants, including Physical Uplink Shared Channel (PUSCH) resource indication, transport format, HARQ related information, and PUSCH power control commands, and        Power control commands for groups of UEs, or terminals (as a complement to the power control commands piggy-backed with the scheduling decisions).        
A PDCCH carries one of the above messages. As multiple mobile terminals can be scheduled simultaneously, on both downlink and uplink, there must be a possibility to transmit multiple scheduling messages within each subframe. Each scheduling message is transmitted on a separate PDCCH. Consequently, there are typically multiple PDCCHs in each cell, and each mobile terminal monitors multiple PDCCHs.
The different scheduling messages have different payload sizes. For example, a downlink scheduling grant supporting spatial multiplexing with non-contiguous allocation of resource blocks in the frequency domain requires a larger payload size than an uplink scheduling grant supporting frequency-contiguous allocations only. Link adaptation, i.e., to match the code rate of the error-correcting code of the PDCCH to the instantaneous radio conditions, is also supported. Thus, there are multiple formats for the PDCCH where each format is defined by the payload size and the code rate.
The processing of the PDCCH is illustrated in FIG. 1. As illustrated, a Cycle Redundancy Check (CRC) is attached to each PDCCH payload, where the Medium Access Control (MAC) Identifier (ID) (Radio Network Temporary Identifier (RNTI)) is included in the CRC calculation. Upon reception of a PDCCH, the mobile terminal will check the CRC using its own RNTI. If the CRC checks, the message provided on that PDCCH is declared to be correctly received and intended for the mobile terminal. Thus, the identity of the mobile terminal that is supposed to receive the PDCCH message is implicitly encoded in the CRC and not explicitly transmitted.
After CRC attachment follows channel coding with a 1/3 rate tail-biting convolution code, rate matching, and Quadrature Phase Shift Keying (QPSK) modulation. Depending on the PDCCH message size and the channel coding rate (including rate matching), the size of the coded PDCCH corresponds to 1, 2, 4, or 8 Control Channel Elements (CCEs), where each CCE corresponds to 36 resource elements or 9 Resource Element Groups (REGs) as shown in FIG. 2.
The coded and modulated PDCCHs are multiplexed such that all CCEs corresponding to the first PDCCH are followed by all the CCEs corresponding to the second PDCCH and so on. The multiplexed CCEs are then mapped to resource elements, which is described as an interleaving of groups of four QPSK symbols followed by a cell-specific cyclic shift. Groups of four QPSK symbols are used for the same reasons as for the Physical Control Format Indicator Channel (PCFICH), namely to support the different transmit diversity schemes, and the cyclic shift serves the purpose of randomizing the mapping between different cells. Resource elements not used for PCFICH, Physical HARQ Indicator Channel (PHICH), or reference signals in the control region are used for transmission of the PDCCH. Furthermore, to obtain an even power distribution between the Orthogonal Frequency Division Multiplexing (OFDM) symbols and to allow for flexible power control, the mapping is done such that each CCE spans all OFDM symbols in the control region.
Each PDCCH (or enhanced PDCCH (ePDCCH)) supports multiple Downlink Control Information (DCI) formats. The format used for a particular PDCCH is unknown to the mobile terminal and, as such, the mobile terminal needs to blindly detect the PDCCH. While the CCE structure described above helps to reduce the number of blind decoding attempts, LTE utilizes so called “search spaces” to further reduce the number of blind decoding attempts needed at the mobile terminal. A search space is a set of candidate channels formed by CCEs at a given aggregation level that the mobile terminal is supposed to attempt to decode. In general, there are two types of search spaces, namely, a common search space and a UE-specific search space. One example of a common search space and UE-specific search spaces is illustrated in FIG. 3. The idea is to send information intended for all or several UEs in the common search space, e.g. indications about paging. All UEs monitor the common search space on PDCCH. The UE-specific search space is intended for only one UE. It can consist of, e.g., scheduling grants for transmitting uplink data. The UE will use its RNTI (UE specific or temporary Cell RNTI (C-RNTI)) to find its specific search space. Furthermore, both common and UE-specific search spaces have PDCCH format restrictions, as shown in the table below.
TABLE 1Number ofPDCCHTypeNumber of CCEsSize [in CCEs]CandidatesUE-Specific16621264828162Common41648162Notably, Table 1 is in accordance with 3GPP TS 36.213 Section 9.1.1 describing the PDCCH assignment procedure. The CCEs corresponding to PDCCH candidate m of the search space Sk(L) are given byL·{(Yk+m)mod [NCCE,k/L]}+i whereYk is defined in the standard, i=0, . . . , (L−1) and m=0, . . . , M(L)−1. M(L) is the number of PDCCH candidates to monitor in the given search space. In Table 1, “Number of CCEs” represents the aggregation level (L) corresponding to search space Sk(L) and “Number of PDCCH Candidates” corresponds to M(L) in the above equation.
The downlink assignments consist of resource block indication, modulation and transport block size, HARQ related information, PUCCH power control commands, and (if applicable) information related to spatial multiplexing. Resource block indications can be of three different types: 0, 1, and 2. Type 0 and 1 use a bitmap to support non-contiguous allocations in the frequency domain. In type 0, each bit in the bitmap represents a group of n contiguous resource blocks, where n is given by the downlink system bandwidth. The reason for grouping resource blocks is to reduce the size of the bitmap; a bitmap with the resolution of one resource block in the frequency domain would result in a too large overhead for larger system bandwidths. However, a frequency resolution of one resource block is also sometimes useful in large system bandwidths. Therefore, type 0 is complemented by type 1, where the resource blocks are divided into subsets as shown in FIG. 4, which illustrates the different types of downlink resource block assignments. Within the subset used, a bitmap indicates upon which resource blocks the PDSCH is transmitted. For resource allocation Type 2, a Resource Indication Value (RIV) is transmitted that indicates where the contiguous resource blocks start and the length in terms of virtually contiguously allocated resource blocks.
The downlink scheduling assignments are sent to the UE on PDCCH as DCI. The DCI on the PDCCH has several supported formats, as shown in Table 2 below.
TABLE 2DCI FormatResourceon PDCCHAllocation TypeUseDCI 0“Type 2”Scheduling of PUSCHDCI 1Type 0/1One PDSCH code wordDCI 1AType 2One PDSCH code wordor Random accessprocedureDCI 1BType 2One PDSCH code wordwith precodinginformationDCI 1CType 2One PDSCH code wordDCI 1DType 2One PDSCH code wordwith precoding and poweroffset informationDCI 2Type 0/1CL spatial multiplexingDCI 2AType 0/1OL spatial multiplexingDCI 3“Type 2”Power Control, 2-bitpower adjustmentDCI 3A“Type 2”Power Control, 1-bitpower adjustments
DCI format 0 is for uplink and uses an allocation type similar to resource allocation type 2. DCI formats 1, 2, and 2A use resource allocation type 0, which is a bitmap pointing out the allocated resource blocks. DCI format 1A uses resource allocation type 2, which indicates start and length of the allocation of resource blocks, i.e. RIV. DCI format 1 is used for transmit diversity, while DCI format 2 is used for closed loop spatial multiplexing and DCI format 2A is used for open loop spatial multiplexing. DCI formats 1, 2, and 2A could use type 0 or type 1 resource allocation. This is solved by a single bit resource allocation header field which exists depending on the downlink system bandwidth where type 0 is indicated by 0 value and type 1 is indicated otherwise.
As an example, DCI format 1A consists of the following information:                1 bit for the format flag for PDSCH allocation                    Used to indicate NRB assignment for Random Access RNTI (RA-RNTI), Paging RNTI (P-RNTI), or System Information RNTI (SI-RNTI)                        1 bit to indicate localized/distributed Virtual Resource Block (VRB) assignment        N bits for the resource block assignment (depends on NDLRB)        5 bits for the Modulation and Coding Scheme (MCS)        3 bits (Frequency Division Duplexing (FDD)) or 4 bits (Time Division Duplexing (TDD)) HARQ process number        1 bit for new data indicator (indicates gap size for overhead messages)        2 bits for Redundancy Version (RV)        2 bits for Transmit Power Control (TPC) command for PUCCH        2 bits for Downlink Assignment Index (DAI) (TDD only)Zeros are used to pad out the message to fit the correct block size.        
One issue with conventional PDCCH is that, with an increasing number of UEs, the eNB scheduler is not able to fulfill the scheduling requirements of all UEs because of the limitation on the number of simultaneous PDCCHs. This leads to a condition of PDCCH congestion. Similarly, if there are many Guaranteed Bit Rate (GBR) UEs (e.g., UEs using Voice over LTE (VoLTE) services), this will also lead to PDCCH congestion because the eNB scheduler is not able to cope with the delay requirements of GBR UEs. Thus, there is a need for systems and methods for mitigating PDCCH congestion.